REMARKS/ARGUMENTS 



Claims 3-12 and 37-41 are pending in the present application. Claims 3-7, 11, 37 and 38 
have been amended herewith. Reconsideration of the claims is respectfully requested. 

I. 35 U.S.C. § 102, Anticipation 

Claim 3 stands rejected under 35 U.S.C. § 102(b) as being anticipated by Derby et al. 
(U.S. Patent No. 5,426,637), hereinafter "Derby". This rejection is respectfully traversed. 

To anticipate, the prior art must teach all the claim elements and the claimed 
arrangement. Section 102 embodies the concept of novelty — if a device or process has been 
previously invented (and disclosed to the public), then it is not new, and therefore the claimed 
invention is "anticipated" by the prior invention. . . . Because the hallmark of anticipation is prior 
invention, the prior art reference — in order to anticipate under 35 U.S.C. § 102 — must not only 
disclose all elements of the claim within the four corners of the document, but must also disclose 
those elements "arranged as in the claim." Focusing for a moment on arrangement - to 
anticipate, the reference must teach "all of the limitations arranged or combined in the same way 
as recited in the claim." Net Moneyln v. Verisign (Fed. Cir. 2008). Applicants will now show 
that Derby does not teach all of the limitations arranged or combined in the same way as recited 
in Claim 3, and therefore Claim 3 has been erroneously rejected under 35 U.S.C. § 102(b). 

Generally, Claim 3 is directed to a method of balancing demand for network services. 
The cited Derby reference is instead directed to a technique for interconnecting LANs to a WAN, 
and provides no type of network service demand balancing, as per Claim 3. 

With respect to Claim 3, such claim recites "initializing one or more local service 
managers within the distributed data processing system, wherein each local service manager has 
information about and provides access to networked services defined within a respective local 
region of the distributed data processing system for clients within the distributed data processing 
system, and wherein each client is uniquely associated with a local service manager" (emphasis 
added). As can be seen, each local service manager has information about and provides access to 
networked services. In addition, each client is uniquely associated with a local service manager. 

In rejecting Claim 3, the Examiner alleges that Derby teaches the claimed local service 
manager at col. 6, line 10. There, Derby describes a 'LAN access agent'. However, this Derby 
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'LAN access agent' is not equivalent to the claimed 'local service manager' since the Derby 
'LAN access agent' does not have a client uniquely associated with it. Importantly, Derby 
cannot have a client uniquely associated with the LAN access agent since such LAN access 
agent provides an interface between a LAN and a WAN in order to facilitate all LAN traffic for 
multiple users/clients (Derby col. 5, lines 56-58; col. 6, lines 55-59; col. 14, lines 34-36). Derby 
does not teach "wherein each client is uniquely associated with a local service manager" as a 
part of a network services demand balancing technique, and therefore Derby does not anticipate 
Claim 3 as such reference does not teach all of the limitations arranged or combined in the same 
way as recited in the claim. 

Further with respect to Claim 3, and as alluded to above, the claimed local service 
manager has information about and provides access to networked services defined within a 
respective local region of the distributed data processing system. The cited reference does not 
describe that its LAN access agent - which the Examiner alleges as being equivalent to the 
claimed local service manager - has information about and provides access to networked 
services defined within a respective local region for at least two reasons. First, the Derby LAN 
access agent is not described as having any information about networked services. Secondly, the 
Derby LAN access agent is not described as providing access to networked services defined 
within a respective local region. In fact, Derby is keen on merely providing a conduit for data 
traveling long distances between a plurality of LANs and a WAN (Derby col. 5, lines 30-53), 
and therefore would have no need to provide access to local region network services due to the 
desire to provide remote access for all services. Thus, it is further urged that Claim 3 has been 
erroneously rejected as Derby does not teach all of the limitations arranged or combined in the 
same way as recited in the claim. 

It is further noted that Derby does not provide any type of network service demand 
balancing , and therefore does not teach network service demand balancing using the 
methodology expressly recited in Claim 3. Thus, it is further urged that Claim 3 has been 
erroneously rejected as Derby does not teach all of the limitations arranged or combined in the 
same way as recited in the claim. 

Therefore, the rejection of Claim 3 under 35 U.S.C. § 102(b) has been overcome. 
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II. 35 U.S.C. § 103, Obviousness 

Claims 3-7 and 38-39 stand rejected under 35 U.S.C. § 103 as being unpatentable over 
Elnozahy et al. (U.S. Patent No. 6,014,686), hereinafter "Elnozahy" in view of Chandra et al. 
(U.S. Patent No. 6,457,047), hereinafter "Chandra". This rejection is respectfully traversed. 

With respect to Claim 3, such claim recites both a local service manager (one or more) 
and a distributed service manager (one or more), where each distributed service manager 
provides access to networked services to the local service manager(s). 

In rejecting Claim 3, the Examiner alleges that Elnozahy teaches both types of managers 
by the 'Cell Directory Service' and the 'CDS server'. Applicants urge that these are the same 
thing, as the CDS part of 'CDS server' stands for 'Cell Directory Service, as described by 
Elnozahy at col. 1, line 49. Importantly, Elnozahy does not describe a Cell Directory Service 
that is separate from the CDS server - indeed the CDS server it what is used in providing the 
Elnozahy Cell Directory Service, as described by Elnozahy at col. 2, line 56 - col. 3, line 13 and 
col. 5, lines 23 ("The highly available CDS in accordance with the principles of the present 
invention consist of two main components: standard CDS servers 62 and 72 and high 
availability agents 68 and 76"). 

As yet another example of how the Examiner is impermissibly double counting the 
described Cell Directory Service that is provided by the CDS server, the cited reference does not 
describe two separate initialization steps for each of its 'CDS server' and 'CDS' as they are one 
and the same thing. In contrast, Claim 3 recites two separate initialization steps, with one 
pertaining to local service manager(s) and another pertaining to distributed service managers. 

A person of ordinary skill in the art also would not have been motivated to modify 
Elnozahy to include a separate initialization step with respect to the CDS and the CDS server, as 
the CDS server itself provides the CDS functionality so there is no need for a separate 
initialization for both the Elnozahy CDS and CDS server, which are one and the same. Thus, for 
this reason alone it is urged that Claim 3 has been erroneously rejected due to this prima facie 
obviousness deficiency. 1 



1 In rejecting claims under 35 U.S.C. Section 103, the examiner bears the initial burden of presenting a 
prima facie case of obviousness. In re Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 
1992). Only if that burden is met, does the burden of coming forward with evidence or argument shift to 
the applicant. Id. All words in a claim must be considered in judging the patentability of that claim 
against the prior art." MPEP 2143.03; In re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 
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Further with respect to Claim 3, such claim recites "receiving, at a distributed service 
manager, a request for a networked service from a local service manager for which the local 
service manager lacks information". As can be seen, this aspect of Claim 3 is directed to 
interaction between a distributed service manager and a local service manager, where a network 
service request is received at a distributed service manager, with such request being from the 
local service manager. 

The Examiner fails to address such receiving aspect of Claim 3 in their rejection of such 
claim. Instead, the Examiner merely alleges that Elnozahy teaches two initializing steps, and 
Chandra teaches distributed application caching (see, e.g., page 5 of the present Office Action 
dated June 2, 2009). This failure to allege the claimed teaching step is likely because of 
problems associated with the improper double counting with respect to the Elnozahy CDS 
service provided by the CDS server. Because the Examiner equates Elnozahy' s CDS as being 
equivalent to the claimed 'local service agent' and Elnozahy' s CDS server as being equivalent to 
the claimed 'distributed service manager', in order for Elnozahy to teach the claimed receiving 
step, it would have to describe receiving, at the CDS server, a request for a network service from 
the CDS for which the CDS lacks information. Because the CDS server provides the CDS 
service, the CDS service would never initiate a request to its own CDS server for information 
that it lacks because if it lacks the information, so would the CDS server as the CDS server 
provides the functionality of the CDS service - restated, it would not ask itself for information it 
does not have since it does not have the information. Thus, it is further urged that Claim 3 has 
been erroneously rejected due to this additional prima facie obviousness deficiency. 

Applicants initially traverse the rejection of Claim 4 for reasons given above with respect 
to Claim 3 (of which Claim 4 depends upon). 

Further with respect to Claim 4, such claim recites "sending a request for a networked 
service from a requesting client to a local service manager associated with the requesting client; 
and returning information for referencing a matching networked service from the local service 
manager to the requesting client, wherein the matching networked service has characteristics that 

1970). If the examiner fails to establish a prima facie case, the rejection is improper and will be 
overturned. In re Fine, 837 F.2d 1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). In the absence of 
a proper prima facie case of obviousness, an applicant who complies with the other statutory requirements 
is entitled to a patent. See In re Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). 
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match parameters in the request for a networked service". As can be seen, the features of Claim 
4 are directed to a requested network service, where a request for such networked service is sent, 
and information is returned for a matching networked service, where the matching network 
service has characteristics that match parameters in the request. 

In rejecting Claim 4, the Examiner cites Chandry col. 6, lines 20-34 as teaching the 
returning of matching network service information. Applicants show that there, Chandry states: 

In step 72, the cache directory receives an incoming query from a user. Using the 
table stored in the cache directory as described above, the dispatcher in the cache 
directory may determine if the query is cached in the system in step 74. If the 
query has been previously cached, then the cache directory will direct the 
cached result to the user to fulfill the user's query in step 76. This is the best 
solution since there will be minimal latency since the query does not need to be 
repeated. This solution also saves computing resources since the query does not 
need to be repeated. If the query has not been cached, then the cache directory 
determines if the application cache (AC) computer on the same LAN as the user 
can service the query in step 78. The AC can service the query if it has the 
appropriate program and data to execute the query. 

As can be seen, this cited passage describes the returning of a query result, the query result that is 
returned being the result of a query that was previously run against a database and is now in a 
local cache (Chandry col. 2, lines 15-51). One example given of such database query result is a 
list of companies whose stock price is between $50 and $55 (Chandry col. 3, lines 54-61). The 
returning of the result of a database query - as described by Chandry at the cited passage at col. 
6, lines 20-34 - does not teach or suggest returning information for a matching network service , 
as claimed. 

Applicants traverse the rejection of Claim 5 for reasons given above with respect to 
Claim 3 (of which Claim 5 depends upon). 

Applicants initially traverse the rejection of Claims 6 and 7 for reasons given above with 
respect to Claim 3 (of which Claims 6 and 7 ultimately depend upon). 

Further with respect to Claim 7, such claim recites "responsive to a determination that the 
distributed service manager does not have information about one or more matching networked 
services, broadcasting the request for a networked service from the distributed service manager 
to all distributed service managers in the distributed data processing system". As can be seen, in 
response to it being determined that the distributed service manager does not have information 
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about a matching service, the request for a networked service is broadcast to all distributed 
managers in the distributed data processing system. 

In rejecting Claim 7, the Examiner alleges that all such broadcasting aspects of such 
claim are taught by Chandra at col. 6, lines 35-61. Applicants show that there, Chandra states: 



If the AC local to the user has the appropriate facilities, then the AC executes the 
query in step 80 and returns the query results to the user. The local AC may also 
store the query results and forward the query results to the cache directory so that 
similar future queries may be more easily satisfied. If the AC local to the user 
cannot server the query, then the cache directory may select an AC near the 
user and download/forward the necessary program and data to execute the 
query in step 82 so that that AC can execute the query. This option is the least 
desirable since it requires forwarding the program and data to the AC, but ensures 
that the query is executed as close to the user as possible so that the latency due to 
distance between the user and the AC is minimized. In step 84, the cache 
directory updates its table to reflect that the particular AC has the necessary 
programs and data to execute the query. In step 86, the AC near the user executes 
the query. In step 88, the AC forwards the results to the user and stores a copy of 
the results on the AC. The AC may also forward the results to the cache directory. 
In this manner, each service request received by the application caching system is 
executed in the most efficient manner without requiring a copy of the program 
and data at each node in the network. Thus, the application caching system 
reduces the amount of redundancy in the network, but ensures that all service 
requests are handled in the most efficient manner. Now, an example of the 
application caching in accordance with the invention will be described. 

As can be seen, this cited passage describes a conditional step being performed 
(download/forward the necessary program and data to another AC so that another AC can 
execute a query), with the triggering condition being that the AC local to the user cannot server 
(sic - should be 'service') the query. It is urged that both the triggering condition and the 
resulting action are different from what is recited in Claim 7. 

For example, the Chandra 'condition' is whether the AC local cannot itself service the 
query. In contrast, the claimed 'condition' is whether the distributed service manager does not 
have information about one or more of the matching network services . As another example, the 
Chandra 'resulting action' is the downloading/forwarding of necessary programs and data to 
another computer such that the other computer can execute the query. In contrast, the claimed 
'resulting action' is broadcasting the request for a networked service from the distributed service 
manager to all distributed service managers in the distributed data processing system. Thus, it is 
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further urged that Claim 7 has been erroneously rejected due to this additional prima facie 
obviousness deficiency. 

Applicants initially traverse the rejection of Claim 38 for reasons given above with 
respect to Claim 3 (of which Claim 38 depends upon). 

Further with respect to Claim 38, such claim recites "determining, based on the request, 
whether to return a single matched network service of the set of matched network services or the 
set of matched network services". As can be seen, a determination is made whether to return a 
single matched network service or a set of matched network services, where such determination 
is based on the request for the network service. 

In rejecting Claim 38, the Examiner alleges that Chandra teaches such single/set 
determination at col. 6, lines 20-34. Applicants show that there, Chandra states: 

In step 72, the cache directory receives an incoming query from a user. Using the 
table stored in the cache directory as described above, the dispatcher in the cache 
directory may determine if the query is cached in the system in step 74. If the 
query has been previously cached, then the cache directory will direct the cached 
result to the user to fulfill the user's query in step 76. This is the best solution 
since there will be minimal latency since the query does not need to be repeated. 
This solution also saves computing resources since the query does not need to be 
repeated. If the query has not been cached, then the cache directory determines if 
the application cache (AC) computer on the same LAN as the user can service 
the query in step 78. The AC can service the query if it has the appropriate 
program and data to execute the query. 

As can be seen, this cited passage describes an incoming 'query', where a determination is made 
as to whether the query is already cached. If so, the cached 'result' of the query is returned to the 
user. If not, a determination is made if the AC computer can service the query. It is urged that a 
teaching of (1) returning a cached query result, if cached and (2) determining whether another 
computer can service a query, if not cached does not teach or suggest a determination is made 
whether to return a single matched network service or a set of matched network services, where 
such determination is based on the request for the network service. Thus, it is further urged that 
Claim 38 has been erroneously rejected due to this additional prima facie obviousness 
deficiency. 

Applicants traverse the rejection of Claim 39 for reasons given above with respect to 
Claim 3 (of which Claim 39 depends upon). 
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Therefore, the rejection of Claims 3-7 and 38-39 under 35 U.S.C. § 103 has been 
overcome. 

III. 35 U.S.C. § 103, Obviousness 

Claims 8-12 and 41 stand rejected under 35 U.S.C. § 103 as being unpatentable over 
Elnozahy in view of Chandra, and further in view of Jindal et al. (U.S. Patent No. 6,324,580), 
hereinafter "Jindal". This rejection is respectfully traversed. 

Applicants initially urge error in the rejection of Claim 8 for similar reasons to those 
given above with respect to Claim 3 (of which Claim 8 depends upon). 

Further with respect to Claim 8, such claim recites "in response to a determination that 
the distributed service manager has information about two or more matching networked services, 
selecting a single networked service at the distributed service manager". As can be seen, the 
features of Claim 8 pertain to an action being performed (selecting a single networked service) 
that occurs when another action occurs (the distributed service manager has information about 
two or more matching networked services). 

In rejecting Claim 8, the Examiner states that Elnozahy in view of Chandra fail to 
disclose using load balancing to distribute the selection of a resource. The Examiner goes on to 
state that "Jindal disclosed the use of load balancing to select a preferred server to access a 
distributed network service". Applicants respectfully submit that Claim 8 is directed to 
performing a particular action (selecting a single networked service) that occurs when another 
action occurs (the distributed service manager has information about two or more matching 
networked services). The Examiner has not alleged a teaching/suggestion of - and the cited 
references do not in fact teach or suggest - the specific claimed feature recited in Claim 8 of "m 
response to a determination that the distributed service manager has information about two or 
more matching networked services, selecting a single networked service at the distributed service 
manager". Therefore, Claim 8 has been erroneously rejected due to this prima facie obviousness 
deficiency. 

Applicants initially urge error in the rejection of Claim 9 for similar reasons to those 
given above with respect to Claim 8 (of which Claim 9 depends upon). 

Further with respect to Claim 9, such claim recites "performing a load balancing 
operation at the distributed service manager to select the single networked service". As can be 
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seen, the features of Claim 9 are directed to characteristics of where the load balancing operation 
is performed. In particular, such load balancing is performed at the distributed service manager 
of Claim 3. There, the distributed service manager is defined as providing access to network 
services to local service managers that are each uniquely associated with a distributed service 
manager. 

In rejecting Claim 9, the Examiner alleges that all features of Claim 9 are taught by Jindal 
at col. 4, lines 49-67. Applicants urge clear error, as Jindal describes performing load balancing 
in a centralized domain name server (DNS) that is not described as providing access to network 
services to local service managers that are each uniquely associated with a distributed service 
manager, as per Claim 9 in combination with independent Claim 3. Therefore, it is further urged 
that Claim 9 has been erroneously rejected due to this additional prima facie obviousness 
deficiency. 

Applicants traverse the rejection of Claim 10 for reasons given above with respect to 
Claim 9 (of which Claim 10 depends upon). 

Applicants initially urge error in the rejection of Claim 1 1 for reasons given above with 
respect to Claim 10 (of which Claim 11 depends upon). 

Further with respect to Claim 11, such claim recites "comparing one or more of network- 
related metrics associated with a network path between a requesting client and a providing 
server". As can be seen, the features of Claim 11 pertain to network-related metrics associated 
with a path between a requesting client and a providing server that used for the comparing step 
of Claim 10. 

In rejecting Claim 11, the Examiner cites Jindal col. 6, lines 8-15 as teaching all aspects 
of Claim 11. Applicants show that there, Jindal states: 

The various pieces of information that may be collected illustratively include: 
whether a server or instance of a replicated service is operational; the response 
time for a request submitted to a server or service instance; the number of requests 
processed by or pending on a server or service instance, a server's proximity (e.g., 
the number of network hops necessary to reach the server from nameserver 100), 
etc. 

As can be seen, this cited passage describes the various pieces of information that may be 
collected, including: (1) whether a server is operational; (2) the response time for a request 
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submitted to a server; (3) the number of server requests; and (4) a server's proximity to the 
nameserver. As can be seen, all of the characteristics are specific to the server itself. None of 
these described pieces of information are described as being associated with a particular network 
path between a requesting client (depicted by element 120 of Jindal Figure 1) and a server 
(depicted by elements 110, 112 and 1 14 of Figure 1). At best, this cited passage describes use of 
the network path between the nameserver 100 of Jindal Figure 1 and the servers 110, 112 and 
1 14 of Figure 1 . Because Jindal does not describe any ability to obtain network characteristics 
pertaining to network 122 of Figure 1, of which a requesting client attaches to, it would have no 
way of implementing the client/server path characteristics expressly recited in Claim 11. Thus, it 
is further urged that Claim 1 1 has been erroneously rejected due to this additional prima facie 
obviousness deficiency. 

Applicants traverse the rejection of Claim 12 for reasons given above with respect to 
Claim 11 (of which Claim 12 depends upon). 

Applicants initially urge error in the rejection of Claim 41 for reasons given above with 
respect to Claim 7 (of which Claim 41 depends upon). 

Further with respect to Claim 41, such claim recites "wherein each of the distributed 
service managers includes a localization module, wherein the parameters within respective 
localization modules are tailored to provide different load balancing for corresponding 
distributed service managers". As can be seen, the features of Claim 41 are directed to particular 
characteristics of the distributed service managers, and in particular that each of the distributed 
service managers includes a localization module having load balancing parameters. 

In rejecting Claim 41, the Examiner alleges that all features of Claim 41 are taught by 
Jindal at column 4, lines 49-67. Applicants show that there, Jindal states: 

In yet another embodiment of the invention, status objects 200a, 200b and 200c 
are configured to determine whether a particular service (e.g., web service, 
electronic mail service), application program or server is operational. 
Illustratively, the status objects in this embodiment issue a Connect (or similar) 
command to the target service or server. If a Connect command is successful the 
issuing object knows that the target is operational, otherwise it is assumed to be 
inoperative. 

Illustratively, for each replicated service (or application) that is to be monitored 
(i.e., that is subject to load balancing) on a server, a separate status object operates 
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on nameserver 100. In addition, each status object illustratively performs a single 
function (e.g., determine response time, determine a server's distance from 
nameserver 100). In alternative embodiments of the invention, however, a single 
status object may monitor multiple servers or services and/or perform multiple 
functions. 

In FIG. 2, individual monitor objects (IMO) 202a, 202b and 202c also reside and 
execute on nameserver 100. A separate IMO is depicted for each instance of the 
replicated service. 

This cited passage describes a plurality of status objects that each performs a single function. 
These status objects are not described as having a localization module having parameters therein 
that are tailored to provide different load balancing for corresponding distributed service 
managers. Instead, they provide a single status acquisition function (col. 6, lines 59-60). 

This cited passage also describes a plurality of individual monitor objects. However, 
these monitor objects are not described as having a localization module having parameters 
therein that are tailored to provide different load balancing for corresponding distributed service 
managers. Instead, they provide status object invocation and the collecting of information from 
the status objects (col. 7, lines 1-4). 

Thus, this cited passage does not describe wherein each of the distributed service 
managers includes a localization module, wherein the parameters within respective localization 
modules are tailored to provide different load balancing for corresponding distributed service 
managers, as specifically recited in Claim 41. Thus, it is further urged that Claim 41 has been 
erroneously rejected due to this additional prima facie obviousness deficiency. 

Therefore, the rejection of Claims 8-12 and 41 under 35 U.S.C. § 103 has been overcome. 

IV. 35 U.S.C. § 103, Obviousness 

Claim 37 stands rejected under 35 U.S.C. § 103 as being unpatentable over Elnozahy in 
view of Chandra as applied to Claim 3 above, and further in view of Fowlow et al. (U.S. Patent 
No. 5,920,868), hereinafter "Fowlow". This rejection is respectfully traversed. 

With respect to Claim 37, such claim recites "configuring the local service manager to 
not provide access to object request broker (ORB) services that provide internal service and 
which are valid only in a scope of a local ORB; configuring the local service manager to provide 
access to ORB services that are instantiated on each ORB only through requests based on an 
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ORB identifier; and configuring the local service manager to provide access to ORB services that 
may be accessed from outside the scope of the local ORB through requests based on both a 
service specification string and an ORB identifier". As can be seen, the features of Claim 37 are 
directed to the interplay between the 'local service manager' and the 'object request broker' . 

In rejecting Claim 37, the Examiner states that Elnozahy in view of Chandra fail to 
disclose the use of object request broker services in accessing services in a distributed 
environment. The Examiner goes on to state the Fowlow discloses 'accessing objects in a 
distributed system using an ORB service'. However, even assuming such assertion is true, such 
generalized assertion does not establish a teaching or suggestion pertaining to the specific 
features recited in Claim 37, such as specially configuring the local service manager to either 
provide access to ORB services or not provide access to ORB services based upon particular 
ORB characteristics, as is specifically recited in Claim 37. Thus, Claim 37 has been erroneously 
rejected as the Examiner has failed to properly establish prima facie obviousness. 

Applicants further traverse the rejection of Claim 37 for similar reasons to those given 
above with respect to Claim 3, and such claim has been amended to be in independent form and 
now includes the features of Claim 3. 

Therefore, the rejection of Claim 37 under 35 U.S.C. § 103 has been overcome. 

V. Conclusion 

It is respectfully urged that the subject application is patentable over the cited references 
and is now in condition for allowance. The Examiner is invited to call the undersigned at the 
below-listed telephone number if in the opinion of the Examiner such a telephone conference 
would expedite or aid the prosecution and examination of this application. 

DATE: August 26, 2009 Respectfully submitted, 

/Wayne P. Bailey/ 

Wayne P. Bailey 
Reg. No. 34,289 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorney for Applicants 
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